Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9704/000002_owner-urn-ietf _Wed Apr 2 13:06:30 1997.msg

Internet Message Format | 1997-04-30 | 4KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id NAA17452
    for urn-ietf-out; Wed, 2 Apr 1997 13:06:30 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with SMTP id NAA17447
    for <[e-mail]>; Wed, 2 Apr 1997 13:06:26 -0500 (EST)
Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA19413  (mail destined for [e-mail]); Wed, 2 Apr 97 13:06:18 -0500
Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id MAA06799; Wed, 2 Apr 1997 12:06:22 -0600 (CST)
From: Daniel LaLiberte <[e-mail]>
Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id MAA14411; Wed, 2 Apr 1997 12:06:16 -0600 (CST)
Date: Wed, 2 Apr 1997 12:06:16 -0600 (CST)
Message-Id: <[e-mail]>
To: "Martin J. Duerst" <[e-mail]>
Cc: [e-mail]
Subject: [URN] Hierarchical resolution
In-Reply-To: <Pine.SUN.3.96.970402181630.245K-100000@enoshima>
References: <[e-mail]>
    <Pine.SUN.3.96.970402181630.245K-100000@enoshima>
Sender: [e-mail]
Precedence: bulk
Reply-To: Daniel LaLiberte <[e-mail]>
Errors-To: [e-mail]

Martin J. Duerst writes:
 > In the context of ISBNs, relative URLs will rarely appear.

Probably true.  But the principle is the same.

 > [...] And I still don't see the
 > technical benefits. It seems that you (and others) have
 > scalability in mind. Well, if you use something such as
 > NAPTR, it is as easy to get "contact a server in Japan
 > for all ISBNs starting with a '4'" whether the delimiter
 > is a '/' or a '-'. The same again if you have a prefix
 > such as 0-201- (Addison-Wesley), on the next level.
 > It also does not inhibit you to reuse information
 > obtained in previous NAPTR requests if you still have
 > it around.

You are right.  This is the difference between a hierarchy that is
visible as a path in the identifiers and one that is invisible (in a
standard '/' delimited form) but only exists as a lattice (acyclic
graph) of transformation steps.  The transformation capability, using
NAPTR regular expressions, is more general, but less constraints mean
the client must do more work, and there is more data to be cached.
With a '/'-delimited path, the constraints make parsing trivial.

There is still a question as to whether NAPTR regular expressions will
be deployable.  But a more severe problem is that regular expressions,
as general as they are, are inconvenient or, in some cases, not
sufficient.  For example, reversing a list of components, such as
left-to-right path components, to construct a DNS name for the next
step of the resolution cannot be done with a single regular expression
substitution - it requires a sequence of transformations.

 > There may be multiple hierarchies, such as conceptual
 > hierarchy, resolution hierarchy (different for various
 > resolution services),... Assuming their identity with
 > a single and fixed hierarchy delimiter may be rather
 > contraproductive.

Multiple hierachies, even overlapping hierarchies, are not
incompatible with what I am (we are) thinking.  The forest of
alternative trees can be viewed as a single tree at one level higher.

Using a single delimiter is merely a syntactical issue, but an
important one nevertheless.

You seem to be concerned that a visible path will make the resolution
path fixed.  This is not quite true.  An explicit a path does not
necessarily correspond to a fixed resolution path since each step of
the resolution determines where to go next to resolve the remainder of
the path.  This is similar to a sequence of transformations in being
flexible about the resolution hierarchy.

Furthermore, even if we are resolving a path, one identifier might, in
the end, map to another identifier, and that might map to another,
etc, and thus we get the equivalent of the NAPTR sequence of
identifiers.

--
Daniel LaLiberte ([e-mail])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/